69 research outputs found

    Reasoning about correctness properties of a coordination programming language

    Get PDF
    Safety critical systems place additional requirements to the programming language used to implement them with respect to traditional environments. Examples of features that in uence the suitability of a programming language in such environments include complexity of de nitions, expressive power, bounded space and time and veri ability. Hume is a novel programming language with a design which targets the rst three of these, in some ways, contradictory features: fully expressive languages cannot guarantee bounds on time and space, and low-level languages which can guarantee space and time bounds are often complex and thus error-phrone. In Hume, this contradiction is solved by a two layered architecture: a high-level fully expressive language, is built on top of a low-level coordination language which can guarantee space and time bounds. This thesis explores the veri cation of Hume programs. It targets safety properties, which are the most important type of correctness properties, of the low-level coordination language, which is believed to be the most error-prone. Deductive veri cation in Lamport's temporal logic of actions (TLA) is utilised, in turn validated through algorithmic experiments. This deductive veri cation is mechanised by rst embedding TLA in the Isabelle theorem prover, and then embedding Hume on top of this. Veri cation of temporal invariants is explored in this setting. In Hume, program transformation is a key feature, often required to guarantee space and time bounds of high-level constructs. Veri cation of transformations is thus an integral part of this thesis. The work with both invariant veri cation, and in particular, transformation veri cation, has pinpointed several weaknesses of the Hume language. Motivated and in uenced by this, an extension to Hume, called Hierarchical Hume, is developed and embedded in TLA. Several case studies of transformation and invariant veri cation of Hierarchical Hume in Isabelle are conducted, and an approach towards a calculus for transformations is examined.James Watt ScholarshipEngineering and Physical Sciences Research Council (EPSRC) Platform grant GR/SO177

    The Use of Rippling to Automate Event-B Invariant Preservation Proofs

    Get PDF

    Ideas for a high-level proof strategy language

    Get PDF
    ABSTRACT Finding ways to prove theorems mechanically was one of the earliest challenges tackled by the AI community. Notable progress has been made but there is still always a limit to any set of heuristic search techniques. From a proof done by human users, we wish to find out whether AI techniques can also be used to learn from a human user. AI4FM (Artificial Intelligence for Formal Methods) is a four-year project that starts officially in April 2010 (see www.AI4FM.org). It focuses on helping users of "formal methods" many of which give rise to proof obligations that have to be (mechanically) verified (by a theorem prover). In industrial-sized developments, there are often a large number of proof obligations and, whilst many of them succumb to similar proof strategies, those that remain can hold up engineers trying to use formal methods. The goal of AI4FM is to learn enough from one manual proof, to discharge proof obligations automatically that yield to similar proof strategies. To achieve this, a high-level (proof) strategy language is required, and in this paper we outline some ideas of such language, and towards extracting them. * During this work Gudmund Grov has been employed jointly by University of Edinburgh and Newcastle University. and constrained use of Z [FW08] -is the so-called "posit and prove" approach: a designer posits development steps and then justifies that they satisfy earlier specifications by discharging (often automatically generated) proof obligations (POs). A large proportion of these POs can be discharged by automatic theorem provers but "some" proofs require user interaction. Quantifying "some" is hard since it depends on many factors such as the domain, technology and methodology used -it could be as little as 3% or as much as 40%. For example, the Paris Metro line 14, developed in the Bmethod, generated 27, 800 POs (of which around 2, 250 required user-interaction) [Abr07] -the need for interactive proofs is clearly still a bottleneck in industrial application of FM, notwithstanding high degree of automation. THE FORMAL METHODS PROBLE

    Preface

    Get PDF
    The 15th International Workshop on Automated Verification of Critical Systems was hosted by the School of Mathematical and Computer Sciences within Heriot-Watt University on September 2-4, 2015 in Edinburgh, United Kingdom.  The 6th AI4FM workshop, which was held on 1 September, was co-located with AVoCS
    • 

    corecore